[00:00] The standard transaction group is perhaps the most flexible of transaction groups. Just like other groups, the standard group contains items that can be mapped to a database or used internally for triggers or handshakes. Items that are mapped to a database will target a specific column and a single specific row, chosen according to their group settings. Unlike the Historical Group type where data only flows from ignition to a database, standard groups have modes associated with them. In OPC to DB mode, data can flow from OPC to a database, for OPC data historization. In DB to OPC mode, database data can be mapped to OPC items. Finally, bi-directional modes allow for data synchronization between a database and OPC. The standard group can not only insert new rows into a database table, but it can also update existing rows in the table. Now that we have a basic understanding of the standard group, let's take a look at how it works. From the transaction group design space, I'll create a new standard group named my group.

[01:07] Once it is created, I will head over to my OPC browser and drill down to one of my OPC devices configured on my gateway, and I will drag a few tags from it to my standard group's OPC items list. Notice the mode column for each OPC item by default, it will be set to use groups mode. The groups mode in this case is OPC to DB. My group is configured to use a table named standard. Since this is a new group, This table does not yet exist in my database, so I will check the automatically create table setting to true. There is also other settings available to us, like adding a custom index column, store a quality code for my OPC data, as well as data pruning mechanisms. In contrast to historical groups, standard groups also have table actions associated with them. For now, we want to insert a new row with every group execution, so I will leave the default "Insert New Row" Table Action selected.

[02:02] Currently, my group is disabled. If I enable it and save my changes in the status tab below, I begin to see live statistics for my now enabled transaction group. Checking our database query browser, I'm able to see live OPC data insertions to the database, which is expected using OPC to DB mode. Let's play around with the table actions. Currently, we're inserting a new row with every group execution. If I switch the table actions to "Update/Select", I will be asking the group to update or select database information depending on the groups mode. In OPC to DB mode, database data will be updated with OPC data. In contrast, in DB to OPC mode, data will be selected from the database to update OPC, changing the table action to Update/Select and selecting first. After saving my changes we see in the database query browser that only the first row is getting updated with OPC data. If I set the table action to be last, we see that now the last row was getting updated with OPC data.

[03:05] The table action can be custom as well, which gives you the flexibility to specify a custom work condition to select what database rows should be updated by the transaction group. This configuration will ensure that only the row that has an index of five is updated. On the database, we can see that just as expected, only the row with an index of five is getting updated. The key value pairs table action works in the same fashion as the custom table action. If I select my index column and set it to have a value of say nine, we see that only the ninth index row is getting updated with OPC data. Now that we have seen table actions, let's look at the other transaction group modes. We saw how data can flow from OPC to a database, for both insertions and updates. Changing my group's mode to DB to OPC, If I make a change to the ninth row in my database table, we see that my OPC data point reflects this database site change, as expected with DB to OPC mode.

[04:12] The remaining mode is bi-directional. This mode will ensure that data in a database will always be synchronized with OPC data. There's two modes of Bi-directionality. With DB wins, if the data between the database and OPC differs when the group first starts, the database record will win and will be written to OPC. With OPC wins, if the data between the database and OPC differs when the group first starts, the OPC record will win and will be written to the database. Let's quickly see how this will work. Notice that my ambient temp value is 15. With my group disabled, and with a bi-directional OPC wins mode, if I go to my database and set my ambient temp value to 60, when the group starts, since OPC sees ambient temp to be 15, and the database sees it as 60, OPC data will win and 15 will be written to the database.

[05:09] Setting its mode to bi-directional DB wins, disabling my group once more. Going back to my database and setting ambient temp value to 90. Once the group starts up, since OPC sees ambient temp to be 15 and the database sees it as 90, database data will win and 90 will be written to OPC.